As battery-dependent portable computing devices (notebook computers, personal digital assistants, etc.) have become more prevalent, the conservation of battery power or “power management” has become more and more important. In many power management systems, some or all system components may be deactivated or “powered down” to conserve power. This method however, requires that the devices powered down be inactive or unused for a sufficiently long period of time to justify the latency associated with their re-activation. Therefore, a number of methods have been implemented to decrease device power consumption within the active or “powered on” state. Since, the power dissipated by a device is dependent both on its applied voltage and on the frequency with which device transitions or “switching” occurs, conventional power management techniques typically focus on one or both of these factors.
Modem power management systems implement a variety of voltage and frequency reduction or “scaling” techniques. Although substantial power savings can be realized by reducing a device's voltage, special hardware is often required to correctly operate such devices using low and variable voltages. Such voltage reduction techniques also currently limit the maximum frequency at which a device may be operated. Similar power savings may be realized by scaling a device's operating frequency or “clock”. In conventional power management systems, a device's operating frequency may be altered in a variety of ways. In one approach, the applied clock signal is periodically stopped and restarted such that the average or effective operating frequency is lowered (throttling). In another approach, a lower frequency clock signal, generated independently or derived from an existing clock, is applied to a device. Although these approaches may be used alone or in combination to reduce a device's or system's power consumption, this frequency scaling technique reduces the operating frequency of the device, and consequently the number of operations or tasks it can perform.
In the past, several approaches have been taken to control the activation of the above-described power management techniques such as the user selection of a pre-defined power mode, the occurrence of environmental events such as the application or removal of an A/C (alternating current) power source, or the detection of a system or device temperature. More recently, power management systems have looked to device utilization or “idleness” to trigger the application or removal of such techniques in an effort to conserve power in a more user-transparent manner. When a utilization-based power managed device is idle for a pre-determined period of time, power reduction techniques such as voltage and frequency scaling are applied to decrease the amount of power consumed. The greatest difficulty traditionally associated with such demand-based systems has been in determining a device's current utilization, particularly for processing devices such as the central processing unit (CPU) of a data processing system.
In a conventional operating system (OS), CPU utilization is determined by accumulating CPU idle time across a sampling interval to determine the percentage of time the processor is inactive. To accomplish this, a list of tasks or threads is maintained by the OS which are ready-to-run, i.e., not waiting for some event to resume execution. When this ready-to-run list is empty, no tasks are being executed and the processor is idle. Accordingly, a CPU-independent timer is read and the processor is placed in a low power state. When a new task is added to the ready-to-run list, the processor is placed in an active state and the timer is read again. The difference between the first and second timer reads (multiplied by the timer's period) then represents the CPU's idle time. The accumulation of this time across a sampling interval is then used to determine the CPU utilization (what percentage of the CPU's time is spent idle). Unfortunately, neither this measure of CPU utilization nor the state of the ready-to-run task list is available outside of the OS through a supported application programming interface (API). Consequently, this OS-generated CPU utilization metric cannot be utilized in a “demand” or utilization-based power management system.